Before proceeding with a description of the background art, a brief review of terminology to be used throughout the following description is appropriate.
In an object oriented programming environment, such as Visual C++, the term “object” is used to refer to a computer software component comprising data structures, and procedures (often referred to as methods) for manipulating the data structures. Objects can communicate with one another by sending messages using some form of communications protocol. The procedures of a particular object can be activated by a message sent from another object, where the interior structure of each object is entirely hidden from any other object (a property referred to as encapsulation). Each object can have one or more associated interfaces which specify the communication between two objects. For example, each object can have its own private variables and if a procedure contained within a specific object does not refer to non-local variables then the interface of the object is defined by a parameter list contained within the object. Variables of an object store information but do not define how that information is processed.
Objects are derived from a template or type of object, and the collection of objects that are derived from a particular template are said to form a class. Each object in a class is referred to as an ‘instance’ of that class. A class definition defines the attributes (i.e. properties) of the objects within a particular class. Generally, the objects within a class are ordered in a hierarchical manner such that an object has a parent object (i.e. super-class) at the next higher level in the hierarchy and one or more child objects (i.e. sub-class) at the next lower level. An object is generally mapped to a parent object or a child object by means of a mapping table, often referred to as a sibling table, which is associated with the object.
As described above, each object can have various attributes associated with the object. Attributes can be local to that object, or can be inherited from the parent object. Inheritance is the term given to the manner in which characteristics of objects can be replicated and instantiated in other objects. Attributes of an object can also be inherited from a child object often without limit on the number of inheritances. The object from which all of the objects within the class are derived is referred to as the base class object.
Inheritance is both static by abstract data type and dynamic by instantiation and value. Inheritance rules define that which can be inherited and inheritance links define the parent and child of inheritance attributes.
Generally, an object has a permanent connection with a parent application program. However, some objects (e.g. embedded objects) have no permanent connection with a parent application. In this case, when the object is activated the parent application is generally launched. For example, a button object on a graphical user interface system, when activated, might cause a certain application program to execute in order to perform some function.
Many conventional computer graphical user interface systems, such as the Windows™ graphical user interface system, utilise objects to process asynchronous events such as a mouse click or a key-board press. These asynchronous events are most often generated by a peripheral device and as such, asynchronous events are generally referred to as external events. External events are generally processed by a graphical user interface system using one or more objects which are called by an application program. Some external events may require several different actions (e.g. activating a procedure, calculating a data value, determining the meaning of a key-board press, or the like) to be performed by an application program and as such, many application programs use a certain class of object called an event handler object to process external events. Each external event can be handled by a different event handler object which itself often generates internal events within an application program, and thus event handler objects are generally configured to communicate with one another. However, a certain type of external event (e.g. a mouse click) is generally handled by a certain instance of event handler object (e.g. a mouse event handler object).
Event handler objects communicate with one another by sending messages, as described above, using some form of communications protocol. It is advantageous if such a protocol is “flexible” in that compatibility between event handler objects is not restricted to objects of a certain class. Further, it is advantageous if the protocol is safe in that two or more event handler objects are able to communicate with each other.
Conventional communications protocols for facilitating communications between event handler objects have tended to be to restrictive in that compatibility between different event handler objects has been constrained to objects based upon their class. For example, one conventional graphical user interface system determines compatibility between event handler objects at the time that an application program is compiled by determining the class of each event handler object of the application program. This graphical user interface system requires that an object be a member of a predefined class and an object of one class cannot be connected to an object of a different class.
In addition, conventional protocols which have been pre-configured for flexibility have generally tended to be unsafe. For example, one known graphical user interface system allows objects of any class to be connected to each other. However, this operating system cannot guarantee that these connected objects will be compatible.
Finite state machines are commonly used to model graphical objects. Modelling graphical objects using finite state machines enables the separation of a graphical user interface associated with an object from the implementation of that object. Finite state machines provide a simple automation method where an input data string is read once from left to right looking at each symbol in turn. At any one time the finite state machine is in one of many internal states and the state changes after each symbol is read with the new state depending on the symbol just read and on the source state.
A finite state machine is determined by a state transition function ƒ as follows:ƒ:I×Q→Q where I is the set of possible input symbols, Q is the set of states, and I×Q is the Cartesian product of I and Q. The function ƒ is generally represented either by a state transition table or by a state transition diagram.
Finite state machines can be used to model discrete controls which are commonly used on graphical user interfaces and which a user interacts with to drive a particular graphical user interface Interacting with a control often results in a change to the visual appearance of any graphical objects associated with the control. For example, a button represented on a graphical user interface using one or more graphical objects can be configured to glow when a mouse cursor moves over the button as well as to provide feedback when the button is selected by using a mouse in a conventional manner. More complicated controls such as list boxes can have a larger number of possible visual appearances.
Most conventional graphical user interface controls exhibit instantaneous changes to visual appearance. That is, as soon as a user interaction occurs (e.g. a mouse click), the control is immediately re-rendered to show a changed visual appearance. Unfortunately, the differences between the visual appearance before and after the user interaction is often significant. Thus, even when modelled using a finite state machine, the instantaneous change of visual appearance in a control often appears abrupt and unattractive.